The present application generally relates to dynamic virtual private network (VPN) routing. Embodiments described herein are capable of providing carrier grade performance and low latency. Some embodiments described herein relate to a dynamically routed software defined network (SDN) that can provide true end-to-end obfuscation of both user traffic and user peering information.
Known VPNs can define a secure point-to-point tunnel between two compute devices, an origin and a destination. The level of security across a VPN is largely dependent on the type of encryption that is used to encapsulate the transmission. VPNs typically connect an ingress point to an egress point and are static and easily discoverable. As a result, it is possible for an adversary or interested party to detect the presence of a VPN link and obtain intelligence related to the existence of a link between the ingress point and the egress point even if the traffic itself remains encrypted. Moreover, to alter the topography of a traditional VPN (e.g., change the egress point), the existing link is “torn down” and a new VPN established. This process results in a break in traffic exchange, and the establishment of a new VPN can consume significant network overhead (e.g., relative to an established VPN) and take a significant amount of time (e.g., tens of seconds) to restore communications. A need therefore exists for dynamic VPN routing.
Known VPN techniques implemented across commercial networks (also referred to herein as “clouds”) typically have static ingress and egress points and no or poor control of the route between the ingress point and the egress point. Moreover, users and/or administrators associated with the origin and/or destination compute devices have little or no control over the physical and/or virtual path the VPN tunnel takes across the cloud(s). The VPN tunnel itself can be logically (and in some cases physically) represented by a single point-to-point connection. In the event a VPN tunnel traverses multiple physical servers and/or switches, as may occur when a VPN is implemented using a commercial cloud provider, any intermediate hops within the cloud will typically be outside the control of the VPN provider and users and/or administrators associated with the origin and/or destination compute devices. Moreover, changing the egress point of a known VPN, whether implemented across a cloud or more traditional network infrastructure, typically requires tearing down the existing link and establishing a new VPN from the ingress point to the new egress point, disrupting communications between the origin and the destination.
Additionally, traffic sent across VPNs applying known network virtualization techniques or implemented in a cloud employing known network virtualization techniques will typically take an unpredictable and/or varied path through the physical and/or virtual infrastructure. As a result, known VPNs have inconsistent latencies as, for example, two packets traversing a VPN implemented across a virtual network may take different routes and may arrive out of order. A need therefore exists for customer-defined and/or predictable VPN routing.
Tor and/or onion routing, allows a user to surf the internet with some degree of anonymity by obfuscating the path between the origin and the destination. Tor generally operates through the use of Tor client software installed as a routing application, a Browser Plug-In, or a Tor specific browser. Tor clients and nodes maintain a list of participating Tor nodes in a routing table that is updated via network broadcasts. Tor clients then select a path between the origin and destination by randomly selecting multiple (typically at least three) routing nodes (an ingress node, one or more intermediate nodes, and an egress node) from the list. The Tor client encrypts each packet for each node, creating “layers” of encryption. In transit, each node will strip off one layer of encryption to discover the subsequent routing information and then forward on the encrypted package with one less layer without passing information about the prior node. The egress node is thus the last node in the Tor network to receive the packet and, after decrypting the last layer, the destination address is revealed. The egress node than passes the packet to the destination. Because each packet is encrypted, each node only knows the immediately prior and immediately subsequent node, so in instances in which at least three nodes are used, no one node has both the origination and destination information at the same time. Tor, however, does not allow a client or administrator to select a path through the Tor network. Moreover, Tor operates by broadcasting a node list so that each client and node remain up to date. As a result, an adversary, destination, and/or interested party can recognize the use of Tor by identifying the egress node as belonging to the Tor network. Additionally, like known VPNs, changing the exit node requires terminating the existing connection, selecting an all new set of nodes and renegotiating a connection to a new ingress node, which takes significant time and consumes significant network overhead. A need therefore exists for dynamic VPN routing that enables a user and/or administrator associated with the source device to select a path through the network and that does not broadcast the presence of the network (e.g., broadcasting information identifying the egress node as belonging to a VPN).